The prior art discloses various arrangements for connecting Input/Output (I/O) devices to the central processing unit of a data processing system. As the speed of central processing units increased relative to the speed of the I/O units, it became evident that the function of controlling I/O devices was severely impacting the overall performance of the data processing system. As a result, this control function was separated from the main processor and assigned to the Input/Output Channel Controller (IOCC) which provided the main control interface between the Central Processing Unit (CPU) and the I/O bus to which any number of different types of I/O devices were attached.
In many systems where the system memory is separate from the Central Processing Unit (CPU) and had its own memory controller and memory bus, the IOCC also interfaced with the memory controller so that an input/output data path was established between the I/O devices and the system memory.
When the I/O subsystem involves a limited number of conventional I/O devices such as displays and printers and a disk or tape storage device, the control problem is relatively straightforward since the bus generally does not become overloaded and simple polling schemes and/or priority arrangements can be used quite successfully. As various types of functions are placed outboard of the CPU, the IOCC must be able to accommodate their specific data transfer requirements without impacting the performance of other devices on the bus. In systems where the CPU interrupt control function and the memory refresh function are placed on the I/O bus, the prior art priority screens have been generally acceptable in providing appropriate access to the I/O bus.
In some data processing system applications which involve considerable processing of numerical data, the CPU can be tied up for a period of time. If the system is an interactive system in which an operator must wait for the CPU to complete the numerical processing before being able to proceed, even a period as short as one or two minutes can be quite frustrating for the operator and impact overall system performance. To avoid this type of problem, it has been suggested that the system be provided with the capability of adding a co-processor onto the I/O bus. While such an arrangement is readily implementable, a problem is created in that prior art suggestions for granting access to the bus are no longer valid, since the co-processor requires access to the I/O bus on a regular basis to obtain instructions from the main system memory. Co-processor instruction fetch operations could use the I/O bus efficiently for all periods of time not required to refresh the co-processor memory. If allowed, the co-processor would "hog" the bus to the exclusion of requests from all other devices connected to the I/O bus. The I/O bus, therefore, becomes overloaded since the co-processor could fetch instructions 90% of the time and the memory refresh operation for the co-processor would occupy the remaining 10%.
If all the I/O devices connected to the I/O bus run at full capacity, the bus is over-committed and conventional prior art priority schemes would lock out a device from access to the channel.
An I/O bus arbiter scheme for an I/O subsystem having a co-processor attached to the I/O bus which permits an efficient utilization of the bus by all devices is therefore desirable. The present invention provides such an I/O bus arbiter system for a data processing system.